A virtual private network (VPN) is commonly defined as an overlay network that is built over a public network infrastructure that provides the VPN user (client) a secure, private connection using tunneling, encryption, and authentication [3][8]. When built over an optical network, a VPN is commonly referred to as an optical VPN (O-VPN).
VPNs can be built at layer 2 (L2) of the network, for example using technologies like X.25, Frame Relay, or ATM [5], or at layer 3 (L3) of the network, for example, over the Public Internet using the Internet Protocol (IP) [9]. For convenience, VPNs built at layer 2 of the network are often referred to as L2 VPNs, while VPNs built at layer 3 of the network using IP are often referred to as L3 VPNs or IP VPNs.
L2 VPNs can be client-managed or carrier-managed [7].
In a client-managed VPN, the VPN service provider only provides L2 point-to-point connectivity to the VPN user/client, and the VPN user/client is responsible for L3 connectivity (i.e., routing). Therefore, the user/client is still responsible for designing its L3 topologies on top of the L2 connections.
Another aspect of an L2 VPN is the concept of a closed-user group (CUG) in which a particular site is only “visible” to other sites that belong to the same VPN. For example, in a Frame Relay VPN, a non-member site cannot connect to a member site even if the non-member site knows the DLCI (address) of the member site.
The design of an L3 VPN is generally more complex than that of an L2 VPN. There are three commonly-used interconnections for L3 topologies, namely a full-mesh interconnection, a “hub and spoke” interconnection, and a partial mesh interconnection. The full-mesh interconnection does not scale well because it generally requires on the order of O(N2) L2 point-to-point connections for N L3 devices, and each L3 device generally needs to maintain (N−1) routing adjacencies. The “hub and spoke” interconnection eliminates these problems, although the resulting traffic concentration at the hub can lead to bottlenecks and a single point of failure. The partial mesh interconnection eliminates many of the problems of both the full-mesh interconnection and the “hub and spoke interconnection,” but requires careful and sophisticated network engineering.
In a carrier-managed VPN, the VPN service provider distributes user/client L3 routes on behalf of the user/client. One proposal for distributing user/client L3 routes uses BGP to distribute the routes and uses MPLS for the circuits [9]. Some disadvantages of this proposal are that the edge devices of the service provider's network need to run both EBGP and IBGP, and the user/client needs to trust the service provider with its address information.
It should be noted that, in both a client-managed VPN and a carrier-managed VPN, the service provider must ensure that there is a partition between the user/client routes and the service provider's routes and also between the user/client routes for different VPNs.
Distributing user/client routes using a shared infrastructure has been implemented in ATM using PNNI Augmented Routing (PAR) [1]. PAR uses IPv4 Service Definition Information Group (IG) to carry IPv4 routes inside a PTSE (PNNI Topology State Element), which is similar to a Link State Advertisement in OSPF. Those PTSEs are then flooded to the whole PNNI network. Eventually, the PTSEs will reach to the edge of the PNNI network, where a PAR-capable client interprets such IP-related information. The PAR-capable client is also responsible for generating such PTSEs. One drawback of PAR is that it does not scale well to an optical network having a large number of VPN users/clients.
Routing information exchange over an optical network has been discussed in the VPON (Virtual Private Optical Network) Internet draft [4]. This draft discusses a number of models to perform the exchange over a user-to-network interface channel. One model is a full peer routing model for a flat routing organization in which the optical network and the user/client VPN network run a single instance of a routing protocol (e.g., a single OSPF instance). This model is not suitable for an optical network that is based upon an overlay model for building VPNs. Another model is a full peer routing model for domain specific routing in which each VPN user/client runs its own routing instance (e.g., OSPF, or BGP as in [9]). Another model is a partial peer routing model in which only the optical network only advertises the point of attachment of VPN client devices. Those attachment addresses are then used to connect VPN client devices in a linear (bootstrap) topology that is used just for exchanging routes, and may be changed dynamically after the routes have been exchanged based upon traffic engineering. VPON does not discuss a particular algorithm or method for constructing this initial bootstrap topology.